Event based charging in a communications system

ABSTRACT

A communications system in which event based charging is implemented and in which service flows between end user equipments and application servers are filtered for charging purposes by a traffic plane function (TPF). The TPF identifies a service flow between an end user equipment and an application server and implements event based charging by sending a message to an Event Owner for the service flow requesting notification of Events associated with the service flow. The Event Owner sends a message containing an Event Result to the TPF when an Event associated with the service flow occurs and the TPF correlates the Event Result with the service flow. This correlation may include the matching of the Event Result to the service flow which the TPF then notifies to a billing control function so that the billing control function can bill the end user appropriately based on the Events. This correlation may also include the matching of the Event Result to a data download detected by the TPF on the service flow so that the system operator can confirm that the service flows filtered by the TPF match the Events notified to the TPF by the Event Owner.

FIELD OF THE INVENTION

This invention relates to charging in a communications system based onevents occurring at application servers accessed via the communicationssystem.

BACKGROUND OF THE INVENTION

End users of an Internet Protocol (IP) network, such as a private orpublic internet or intranet may communicate with the IP network via anaccess network. The end user uses an end user equipment such as a mobileor stationary telephone or computing device connected to the accessnetwork in order to send and receive communications over the IP network.The IP network may be made up of several sub-networks interfaced witheach other.

The access network may be a packet switched network, such as a GeneralPacket Radio Service (GPRS) network as defined by the Third GenerationPartnership Project (3GPP). The IP network and the access network aregenerally interfaced by a gateway node of the access network, which isan example of a traffic plane function (TPF). Where the access networkis a GPRS network the gateway node will typically be a Gateway GPRSSupport Node (GGSN). The gateway node transports data packets betweenthe access network and the IP network. For charging purposes the gatewaynode, or a network entity associated with the gateway node, identifiespacket streams or service flows between an end user connected to theaccess network and the IP network. Each packet stream or service flow isa flow of data transported between the access network and the IP networkvia the gateway node and associated with a particular application,service or group of applications and services, such as browsing on aparticular site of the IP network or a VoIP (Voice over IP) ormultimedia call carried over the IP network.

Content based billing (CBB) may be used for charging the end user fortheir use of the communications system. In content based billing, thetraffic plane function (TPF) (eg. the GGSN or other equivalent device)filters the service flows it transports by matching the service flows togiven criteria and measuring the network resource used by a service flowand/or detecting application-level events so that appropriate tariffscan be applied to the service flows based on the matching of thecriteria. For example, network resource may be measured by each filterhaving an associated bucket in which the number of bytes transportedover the service flow associated with that filter is stored. A serviceflow as identified by a gateway may correspond to one or more user dataflows.

In the case of online charging, where an end user has paid up front foraccess to the communications system the TPF is granted a token for anidentified service flow. The token is granted by a Service Control Point(SCP) or Online Charging System (OCS), more generically referred toherein as a billing control function and an example of a billing system.Then the TPF measures the network resource consumed by the service flowand/or detects application-level events and decrements the associatedtoken accordingly. In the case of offline charging, where an end userpays later for access to the communication system, the TPF measures thenetwork resource used by service flows and/or detects application-levelevents and stores the results in a charging log based on instructionsfrom a billing system and/or on gateway local policy. The charging logis sent periodically to the billing system which uses the information tobill the end user.

So far in content based billing the TPF is less aware of the status ofthe application servers to which a service flow relates than isdesirable. Accordingly, the TPF can measure the network resource used bya service flow based only on a limited number of criteria.

In addition, there are service delivery and charging models which theoperator of the communications system (referred to herein as the networkoperator, generally a business organization) may not want to implementfor certain application servers which are operated by a businessorganization different from the network operator and so are not fullytrusted by the network operator. For example, the network operator maybe requested to charge the end user based on information reported by athird party delivering the service. A level of control and/or monitoringby the network operator of the information reported by the third partyis required, beyond that which is currently available, in order for thenetwork operator to verify the reliability of the information reportedto it by the third party. In addition the network operator may wish toensure that the end user is charged only if a service provided by thethird party is successfully delivered, which again requires a level ofcontrol and/or monitoring by the network operator which is not currentlyavailable.

SUMMARY OF THE INVENTION

The present invention relates generally to a communications systemhaving a traffic plane function (TPF) which for billing purposes filtersservice flows between end user equipments and application serverswherein the system correlates an instance of service flow filtered bythe TPF with event results reported by an event owner for the instanceservice flow when events occur at an application server for thatinstance of service flow.

According to a first aspect of the present invention there is provided acommunications system in which event based charging is implemented andin which service flows between end user equipments and applicationservers are filtered for charging purposes by a traffic plane function(TPF), wherein the TPF identifies an instance of service flow and sendsa message to an event owner for the instance of service flow requestingnotification of events associated with the instance of service flow, theevent owner sends a reply message containing an event result when anevent associated with the instance of service flow occurs which eventresult is correlated with the filtered instance of service flow.

According to a second aspect of the present invention there is provideda traffic plane function (TPF) for implementing event based charging ina communications system by filtering service flows between end userequipments and application servers wherein the TPF identifies aninstance of service flow and sends a message to an event owner for theinstance of service flow requesting notification of events associatedwith the filtered instance of service flow.

The TPF may receive the reply message from the event owner when an eventoccurs for the instance of service flow which reply message contains anevent result and the TPF may correlate the event result with thefiltered instance of service flow. Alternatively, an event correlatorremote from the TPF, for example a billing system, may correlate theevent result with the filtered instance of service flow in which casethe message from the event owner may optionally be sent directly to theevent correlator.

According to a third aspect of the present invention there is providedan event owner of an application server for which event based chargingis implemented for service flows between end user equipments and theapplication server by a traffic plane function (TPF) filtering theservice flows for charging purposes, wherein the event owner receives amessage from such a TPF requesting notification of events associatedwith an instance of service flow and in response sends a messagecontaining an event result when an event occurs.

According to a fourth aspect of the present invention there is provideda method for implementing event based charging in a communicationssystem wherein service flows between end user equipments and applicationservers are filtered for charging purposes by a traffic plane function(TPF), the method comprising the steps of:

-   -   the TPF identifying an instance of service flow between an end        user equipment and an application server;    -   the TPF sending a message to an event owner for the instance of        service flow requesting notification of events associated with        the instance of service flow;    -   the event owner sending a reply message in response containing        an event result when an event associated with the instance of        service flow occurs;        wherein the method comprises the additional step of correlating        the event result with the filtered instance of service flow.

The TPF may identify a service flow by matching characteristics of theservice flow to filtering criteria. The instances of a service flowmatching the filtering criteria, for example, may relate to a specificinstance of a given end user equipment, may relate to a specificinstance of end user application or may relate to a specific instance ofend user application window that matched filtering criteria of the TPF.Identifying a given instance of service flow may require supplementalfiltering criteria with a granularity beyond that of the filteringcriteria used by the TPF to identify service flows. In this case a setof additional criteria (associated with the matched filtering criteria)which supplement the filtering criteria may be applied by the TPF so asto distinguish between different instances of service flow. This set maybe an empty set, ie. the instance of service flow may identified by thesame criteria as the service flow which matched the filtering criteria.

The present invention enables a correlation to be made between instancesof service flows filtered by the TPF and one or more events reported byan event owner for those instances of service flow. For example, thecorrelation may be between events the TPF detects on a particularinstance of service flow between an end user and an application serverand the events reported by the event owner in the event results for thatapplication server and instance of service flow. The event owner maysend the reply message to the TPF, in which case the TPF may correlateevents the TPF detects on the instances of service flow it filters withevent reports. The TPF may then forward the correlated information to abilling system which applies appropriate rating so that an end user canbe billed based on events which have occurred on service flows the enduser has used.

Alternatively, information about the TPF detected events and eventresults can be forwarded to a billing system so that the billing systemmakes the correlation and then applies appropriate rating to bill theend user of the end user equipment appropriately, based on events whichhave occurred on service flows the end user has used.

Accordingly, event driven rating and event driven revenue sharing oftraffic, for example based on time and data volume, can be provided. Forexample, for a gaming service, the present invention would enable thedata volume and/or time charges an end user incurs in playing a game tobe taken over by the gaming service provider when the end user wins agame, with the information about the game outcome not being known untilafter the game is completed by the end user. The present inventionenables a billing system to apply a rating decision based on eventresults to charges for usage that has taken place prior to the eventoccurring on the application server and/or before the event ownerreports the event.

In addition or alternatively, the correlation between TPF detectedevents and one or more events reported for that instance of service flowby the event owner can enable the network operator to check that eventsnotified by the event owner to the TPF are in accordance with theresults of the filtering of the instances of service flow by the TPF.Matching or correlating between the two event informations (ie.information from filtering by the TPF and event results) can be carriedout in the TPF or may be outsourced to another entity, such as a billingsystem. Although there are types of events where such correlation is notachievable as the application event cannot be detected by the TPF (forexample because the event is dependent on the state of the applicationserver which is unknown to the TPF), the present invention allows forthe correlation of a wide number of event types, providing the networkoperator with a granular charging control over a large range ofapplications among those typically operated by an event owner.

The identification of a service flow by the TPF may include the TPFmatching characteristics of the service flow with triggering criteria soas to activate a trigger, which trigger may include a specification oftriggering actions to be performed when the triggering criteria is met.The triggering criteria may comprise a set of service flowcharacteristics, such as, source IP address, destination IP address,upper layer protocol, source port, destination port and applicationprotocol based criteria, for example types of application layer messagesand the content of such messages.

For example, the triggering actions specified by a trigger may includeat least one of the following:

-   -   instructions to the TPF on how to filter a service flow matched        to the triggering criteria;    -   instructions to the TPF on how to identify the specific instance        of service flow among those matched to the triggering criteria;    -   instructions to the TPF on how to dynamically filter the        specific instance of service flow;    -   identification of the event owner for a service flow that        matched the triggering criteria;    -   identification of a set of service flow characteristics to be        sent to the event owner for end user and session identification;    -   indication of whether a time stamp should be recorded and        communicated to the event owner;    -   identification of a set of events to be reported by the event        owner;    -   maximum number of events to be reported for the instance of        service flow;    -   maximum number of events allowed for the instance of service        flow before a new message to the event owner from the TPF is        sent; and    -   maximum number of events allowed for the instance of service        flow.

It should also be noted that the TPF may send a request message to theevent owner in relation to an instance of service flow it is filteringupon detecting an event occurring over the instance of service flow.

The event owner may be the application server of the service flow or maybe a different server operated by the operator of the applicationserver. The operator of the application server is generally a businessorganization providing content and applications.

The TPF may allocate a unique identifier to the instance of service flowand may include the unique identifier in the message to the event owner.Then the event owner may include the identifier with the event result inthe reply message. This provides an efficient way of identifyinginstances of service flow, in particular when relaying event resultsand/or TPF detected results for instances of service flow to a billingsystem.

The TPF may include at least one of the following in the message to theevent owner, in accordance with the triggering actions:

-   -   the identifier;    -   a set of flow characteristics for end user and session        identification;    -   information on the set of events to be reported by the event        owner;    -   a timestamp, as recorded by the TPF;    -   a maximum number of events to be reported;    -   a maximum number of events allowed for the instance of service        flow before a new message to the event owner from the TPF is        sent;    -   a maximum number of events allowed for the instance of service        flow.

The event result may contain information enabling the TPF to confirm byfiltering of the instance of service flow that the event has takenplace. For example, the event may be a data download over the instanceof service flow and the event result may contain information about thesize of the download. In this case the TPF can correlate that the amountof data specified in the event result corresponds to the amount of datadetected, for example from information in header packets of thedownload, by the TPF for that instance of service flow. This can alsoenable the network operator to verify that the download is successfulbefore allowing the end user to be charged for the download.

The unique identifier may be exchanged between the TPF and the billingsystem (which may be pre-paid or post-paid) so as to identify instancesof service flow. This allows for the outsourcing to the billing systemof the flow-event correlation and associated rating as well as of theevent matching procedure where the TPF-detected events may be matchedagainst the event results reported by the event owner.

In this way full correlation may be achieved between:

-   -   the instance of service flow that has matched the triggering        criteria in the TPF, possibly generating a TPF-detected event;    -   the user charges related to that instance of service flow and        related events in the billing system including charges relating        to usage that took place before the event occurred or was        reported; and    -   the actions the end user takes on the application server run by        the event owner.

The event may, for example, be one of the following:

-   -   a purchase of goods or services from the application server;    -   a download of data from the application server;    -   access to a specific page on the application server;    -   access to a particular videoclip streaming service on the        application server;    -   completion of a videoclip streaming from the application server;        or    -   a predetermined situation of usage of the application on the        server, for example, the end user has reached a given score in a        gaming application.

The TPF may include a gateway node interfacing an access network of theend user equipment with a further network via which the end userequipment communicates with the application server. For example, theaccess network may be a General Packet Radio Service (GPRS) network andthe gateway may be a Gateway GPRS Support Node.

Other aspects and features of the present invention will become apparentto those ordinarily skilled in the art upon review of the followingdescription of specific embodiments of the invention in conjunction withthe accompanying Figures.

BRIEF DESCRIPTION OF THE DRAWINGS

In order that the present invention is more fully understood and to showhow the same may be carried into effect, reference shall now be made, byway of example only, to the Figures as shown in the accompanying drawingsheets, wherein:

FIG. 1 shows schematically a network operating charging according to thepresent invention including an access network via which an end useraccesses an IP network via which an end user accesses an applicationserver, with the access network and the IP network interfaced by agateway node of the access network;

FIG. 2 shows schematically the exchange of messages between a billingsystem, traffic plane function and event owner shown in FIG. 1 in anexample of pre-paid event based charging according to the presentinvention;

FIG. 3 a shows schematically the actions carried out by and theinteractions between a billing system, traffic plane function, eventowner and application server shown in FIG. 1 according to one embodimentof the present invention;

FIG. 3 b shows schematically the actions carried out by and theinteractions between a billing system, traffic plane function, eventowner and application server shown in FIG. 1 subsequent to those of FIG.3 a according to one embodiment of the present invention; and

FIG. 3 c shows schematically the actions carried out by and theinteractions between a billing system, traffic plane function, eventowner and application server shown in FIG. 1 subsequent to those of FIG.3 a according to another embodiment of the present invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

There will now be described by way of example the best mode contemplatedby the inventor for carrying out the invention. In the followingdescription, numerous specific details are set out in order to provide acomplete understanding of the present invention. It will be apparent,however, to those skilled in the art that the present invention may beput into practice with variations of the specific.

With reference to FIG. 1, an end user having an end user equipment (2),such as a mobile or stationary telephone or computing device, may accessan Internet Protocol (IP) network (6) via an access network (4). Theaccess network (4) may be a packet switched network, such as a GeneralPacket Radio Service (GPRS) network, which is interfaced with the IPnetwork (6) via a gateway node or Gateway GPRS Support Node (GGSN) (8)of the GPRS Network. The IP network (6) may be a public or privateintranet or internet, which may be made up of several interfacednetworks.

The GGSN (8) transports data packets between the access network (4) andthe IP network (6). The traffic plane function (TPF) (being a functionof the GGSN (8) or a distinct physical entity associated with the GGSN),has the functionality to identify the separate packet streams or serviceflows the GGSN carries between each end user (2) and the IP network (6),to measure the stream duration and volume of data carried on each suchservice flow and to detect certain events occurring over service flows.The term gateway used as a general term herein includes a gateway suchas a GGSN (8) and any associated entities in the traffic plane betweenthe GGSN (8) and the IP network (6), involved in the method of chargingaccording to the present invention.

The network includes at least one billing system (10). Where pre-paidonline charging is applied, the billing system may be an OCS or an SCPfor controlling online charging to end users.

The end user of the equipment (2) establishes a GPRS session byrequesting a Primary Packet Data Protocol (PDP) context. The end usermay then access services available on the IP network (6) via the GPRSnetwork (4). The TPF (8) accesses the charging policies and/or rules forthe end user of the equipment (2) and identifies any service flows thatare initiated by the end user of the equipment (2) [box A in FIG. 3 a].

The end user of the equipment (2) accesses an application server (12)via the access network (4) and the IP network (6). The applicationserver (12) has an Internet Protocol (IP) address 111.222.233.244. TheTPF (8) identifies and filters a first service flow (shown in dottedlines in FIG. 1) associated with the end user accessing the applicationserver (12). The gateway (8) is set up by the network operator toassociate a particular trigger with service flows to the applicationserver (12) based on the service flow matching triggering criteria [boxB in FIG. 3 a]. The triggering criteria may be based on a number of thefollowing:

-   -   the source (end user) IP address;    -   the destination (application server) IP address;    -   the upper layer protocol (UDP/TCP/other);    -   the source (end user) port;    -   the destination (application server) port (in most cases this        represents the application protocol identification); and    -   application-level information such as:        -   the identification of a specific application layer message            (eg. HTTP GET); and/or        -   the destination URL or any parameter relevant for the            specific application and conveyed in the application            protocol message parameters; and/or        -   the content of the payload of application layer messages            (eg. the word ‘won’ in the payload of a message).

For example, a rule in the TPF (8) may take the form:Dest=111.222.233.244 trigger 97

Thus, service flows to the application server (12) having IP address111.222.223.224 are associated by the TPF (8) with the trigger no. 97.In this example the triggering criteria is the destination IP address.

A trigger may contain information, referred to herein as triggeringactions. The triggering actions may, for example, instruct the TPF (8)how to filter service flows matched with the triggering criteria,instruct the gateway (8) that event based tariffing is to be applied toservice flows matching that criteria, and may identify for the TPF (8)an event owner (14) associated with service flows matching thatcriteria.

The TPF (8) may be instructed by the triggering actions to apply dynamicfiltering to service flows matching the triggering criteria. Dynamicfiltering aims to select a given instance of service flows among allservice flows that have matched the triggering criteria before and/orwill match it in the future. Thus, dynamic filtering may be based onmore restrictive criteria than the triggering criteria. For example, inthe case of the rule set out above in which the triggering criteria ismet by all service flows to the application server (12), the triggeringactions may instruct the TPF (8) to set up one or more of the followingdynamic filters depending on the desired granularity for theidentification of the instance of service flow:

-   -   a) Dest=111.222.233.244; Source=<source IP address of the packet        that matched the triggering criteria>;    -   b) Dest=111.222.233.244; Source=<source IP address of the packet        than matched the triggering criteria>; Dest Port=<destination        port of the packet that matched the triggering criteria>; and    -   c) Dest=111.222.233.244; Source=<source IP address of the packet        than matched the triggering criteria>; Dest Port=<destination        port of the packet that matched the triggering criteria>; Source        port=<source port of the packet that matched the triggering        criteria>.

The term dynamic stresses that the information, such as Source, andSource Port in the above example may not be available at systemconfiguration time, and so it is dynamically added to the filteringpolicy for a service flow once the triggering criteria is matched bythat service flow. Other information, such as Dest Port (destinationport), though available at system configuration time, may be omitted bythe triggering criteria, to make the triggering criteria more generic,and capture more flows with a single trigger that then dynamicallyspecializes based on the characteristics of the flows that match thetriggering criteria during system operation.

The exact set of dynamic filtering instructions which form part of thetriggering actions and which supplement the triggering criteria so as toimplement dynamic filtering is defined in the triggering actions, and itmay be an empty set.

In addition to those discussed above, the triggering actions associatedwith a trigger may include at least one of the following:

-   -   1) An identification of a set of service flow characteristics to        be sent to the event owner for end user and session        identification. This information enables the event owner to        identify the relevant session on the application server and the        end user;    -   2) An indication of whether a time stamp should be recorded and        communicated to the event owner;    -   3) An identification of the set of events to be reported by the        event owner. If the triggering actions contain this instruction        then, the message sent to the event owner by the TPF will        specify exactly which event or events should be included in        event results;    -   4) An identification of a maximum number of events to be        reported by the event owner for the identified instance of        service flow. If the triggering actions contain this        instruction, then the message sent to the event owner by the TPF        will specify this maximum;    -   5) An identification of a maximum number of events allowed for        the identified instance of service flow before a new message to        the event owner from the TPF is sent. Again, if the triggering        actions contain this instruction, then the message sent to the        event owner by the TPF will specify this maximum; and    -   6) An identification of a maximum number of events allowed for        the identified instance of service flow. Again, if the        triggering actions contain this instruction, then the message        sent to the event owner by the TPF can specify this maximum.

The first service flow matches the triggering criteria of trigger no. 97stored in the TPF (8) [box B in FIG. 3 a]. This trigger no. 97 containsa set of triggering actions indicating that the tariffing of the firstservice flow is to be associated to an ‘event’ owned by an ‘eventowner’. The TPF (8) applies the triggering actions to the service flow[box C in FIG. 3 a]. The TPF (8) analyses the triggering actions toidentify the event owner, which in the case of triggering criteria no.97 is the operator of the application server (12). The event owner maybe identified by a unique code which is statically allocated to eachbusiness partner of the network operator. Each event owner is associatedwith an IP address of a front end server (14) which can provide the TPF(8) with information about application events related to the businesspartner. The TPF (8) implements a dynamic service flow filter inaccordance with the triggering actions no. 97. In this example, thetriggering criteria no. 97 instructs the gateway to filter the serviceflow on a 5-tuple basis. A dynamic filter applying 5-tuple, filters theservice flow based on source IP address, destination IP address,protocol identification, destination port (ie, the port of theapplication server) and source port (ie. the port of the end user). Thismeans that the instance of service flow is identified with a granularitydown to a specific instance of end user application. For example, if thesame end user had two browser windows open accessing the same page onthe same application server, the dynamic filter would be able todistinguish between the two windows and to separately identify the flowsrelated to the different windows.

For example, the end user may open two browser windows towards IPaddress 111.222.233.244, but may generate an application event, forexample, winning a game, in only one of the two windows. The eventowner, may want traffic for the window for which no event occurred to betreated in a different way to the traffic for the window in which theevent occurred, for example to prevent fraud. This granularity isenabled by dynamic filtering based on the source port, where a differentsub-filter and associated sub-bucket is applied to service flows to eachsource port of the end user. The dynamic service flow filter orsub-filters (where appropriate) have a related Bucket for counting thenetwork resource (eg. stream duration, bytes, TPF-detected events)matching the service flow filter, or sub-filter. This is an example,where an event can be linked to a specific instance of service flow witha granularity that goes beyond the parameters that have made the serviceflow match the charging policy.

The gateway allocates an ‘Event Correlator Index’ to each new instanceof service flow that matches the triggering criteria [box D in FIG. 3a]. This is a unique identifier which is dynamically allocated on a perevent type per instance of service flow basis. This identifieridentifies the instance of service flow defined by the dynamic filter,for example using the 5-tuple information set out above. The TPF (8)then sends a message [Box E in FIG. 3 a] to the event owner containing,in this example:

-   -   the set of service flow parameters for end user identification        and application server session identification required by the        event owner as specified in the triggering actions (eg. the        address of the end user and other optional parameters among        those in the above described 5-tuple and/or other application        related criteria as described above);    -   the Event Correlator Index that has been allocated to the        instance of service flow;    -   information on the set of events to be reported by the event        owner as specified in the triggering actions, eg. report when        the end user wins the game;    -   a time stamp, as specified by the triggering actions; and    -   the maximum number of events allowed for the instance of service        flow, eg. one (in the case where the user cannot win more than        once).

Then when the event of the specified type occurs [Box F in FIG. 3 a]within the application server (12), the event owner (14) detects thisand sends a message to the TPF (8) containing the Event Correlator Indexand an ‘event result’ [Box G in FIG. 3 b]. A single ‘event result’ maycontain information about the occurrence of one or more events,depending of the instructions sent to the event owner by the TPF. The‘event result’ is sent by the TPF (8) to the billing system (10) for thebilling system to apply the appropriate rating to the first service flow[Box I in FIG. 3 b]. The event result comprises code identifying thenature of the event or events, which code is recognized by the billingsystem, so that the billing system can apply the appropriate rating. TheTPF (8) doesn't need to understand the event result, it only relays theevent result to the relevant billing system.

In the case of pre-paid charging, with reference to FIG. 2, the TPF (8)may notify the Event Correlator Index to the OCS or SCP (10) when makingthe first token request in respect of an instance of service flow [Box 1in FIG. 2]. The OCS or SCP (10) sends the TPF a token [Box 2 in FIG. 2],which token also specifies the Event Correlator Index. The TPF includesthe Event Correlator Index in the message requesting event notificationit sends to the event owner (14) [Box 3 in FIG. 2]. Then after one ormore of the events have occurred, the event owner (14) replies with anevent result also containing the Event Correlator Index [Box 4 in FIG.2]. The TPF (8) sends event results to the SCP/OCS (10) [Box 5 in FIG.2]. The TPF (8) may jointly also return any partially unused tokensrelating to the instance of service flow. The OCS or SCP (10) thenapplies the appropriate rating to the end user's account based on thereturned token and the one or more events results, as described below.For example, the OCS or SCP (10) may amend, based on the event result,the rating of the entire instance of service flow, possibly issuingrefunds related to previous charges issued for such flow, or additionalcharges.

In the case of post-paid charging, the TPF (8) may record the amount ofnetwork resource consumed by the instance of service flow (eg. countedbytes of data through filter, stream duration, detected events, etc.)and any ‘event results’ associated with that instance of service flow inits Charging Data Records (CDR), ie. its service flow usage log [Box Hin FIG. 3 b]. The CDR is periodically sent by the TPF to the billingsystem (10) so that the billing system can apply appropriate ratingbased on network resource consumed by the service flows and the eventsand charge the end user accordingly [Box I in FIG. 3 b].

In an alternative embodiment, the message sent by the TPF (8) to theevent owner (14) may additionally contain the IP address of the billingsystem (10) and may instruct the event owner (14) to send the ‘eventresult’ along with the associated Event Correlator Index directly to thebilling system (10) [Box J in FIG. 3 c]. In this embodiment, the TPF (8)forwards information about the filtered service flows, such as streamduration, data flow and detected events to the billing system inassociation with the Event Correlator Index [Box K in FIG. 3 b]. Thenthe billing system correlates the ‘event results’ with the informationabout the associated instance of service flow from the TPF (8) using theEvent Correlator Index [Box L in FIG. 3 c] and then applies theappropriate rating, as described below.

TABLE ONE EVENT BILLING EVENT RESULT SYSTEM TPF 1. Purchase PurchaseApply discounted of goods completed rate to instance of service flow 2.Purchase Purchase Charge end user of goods completed according Cost Codeto cost code 3. Download Download Apply discounted of data completedrate to instance of service flow 4. Download Download Charge end user ofdata completed according to Cost Code cost code 5. Download DownloadCompare size of data completed in Event Result Size of to size ofdownload download detected for the instance of service flow 6. Pre-Predetermined Apply discounted determined usage exceeded rate toinstance Usage of service flow 7. Casino Win/lose has Credit/debit winor lose occurred Value end user according of win/lose to value ofwin/lose

Table 1 provides in the first column some examples of events and in thesecond column examples of the information which may be contained intheir associated event results. Column three gives examples of what thebilling system might do on receiving the event results (either directlyfrom the event owner or indirectly via the TPF) of the associated row incolumn two and Column four gives an example of what the TPF might do onreceiving the event result of the associated row in column two.

In examples 1 and 2 in Table 1, the application server (12) may be anE-commerce site and the event is the purchase of something from thesite. Then by using the present invention discounts can be applied tothe traffic charges for access to the site (12) if a purchase takesplace (example 1). In this case, once the billing system (10) isnotified that the event has occurred on an instance of service flow, itapplies the appropriate discount to that instance of service flow. Thiscould include the billing system retrospectively re-rating all of thosecharges which were incurred after the service flow met the triggeringcriteria in the TPF, but before the occurrence of the event in theapplication server. Additionally or, alternatively, by using the presentinvention, where the event result specifies a cost code (example 2), thebilling system can recognise the cost of the purchase from the cost codeand the purchase could be paid for from the end user's account with thenetwork operator (in the case of pre-paid charging) or could be added tothe billing to the end user by the network operator (in the case ofpost-paid charging).

In example 3 and 4, the application server (12) may be a site whichoffers downloads, and the event is a download of data, eg. software ormusic, from the site. Again by using the present invention appropriatediscounts can be applied to the traffic charges if a download takesplaces (example 3) and/or the cost of the download can by paid for fromthe end user's account with the network operator or can be added to theend user's billing (example 4).

In examples 6 and 7, the application server (12) may be a casino site,and a first type of event is a level of Casino usage (example 6) and asecond type of event is a win or lose result at the Casino (example 7).By using the present invention appropriate discounts can be applied tothe traffic charges, for example, if a given level of usage of thecasino service is exceeded, ie. the first type of event occurs (example6). Also, bets can be paid for by the end user and wins can be creditedto the end user via the end user's account with the network operator orvia the network operator billing the end user when the second type ofevent occurs. In this case, the event result would specify the value ofthe credit or the debit and the billing system would apply this to theend user's account or billing.

Where an end user is charged on a per event basis to download largevolumes of data, for example software, music or films, from anapplication server (12) and the network operator does not fully trustthe associated event owner, the network operator may not wish toimplement zero-rated charging for the downloads, on the basis that theevent owner (14) reports downloads to the network operator and pays thenetwork operator accordingly. However, by utilizing the presentinvention, a filter implemented by the TPF (8) can be configured todetect a download taking place [Box C in FIG. 3 a]. The TPF (8) can thencorrelate the detected downloads associated with a given instance ofservice flow with the event results reported for that instance ofservice flow and report them to the network operator [Box H in FIG. 3b]. The network operator is then able to match downloads detected by thegateway for a given instance of service flow with event results reportedfor that instance of service flow. Alternatively, the TPF (8) could beset up to itself match downloads detected by the gateway for a giveninstance of service flow with event results reported for that instanceof service flow. This provides a double check for the network operatorthat the event owner (14) is correctly notifying the TPF (8) when eventstake place on the application server for service flows carried by theTPF. For example, the network operator may require the event to includethe size of a download on an instance of service flow in an event result(example 5 in Table 1) associated with that download over that instanceof service flow, so that the TPF (8) can match the size of datadownloads detected by the filter for that instance of service flow withthe data downloads declared in the event result. In this way the networkoperator can ensure that all downloads are paid for. Also, the networkoperator can ensure that the end user is only charged for successfuldownloads, at least for those services where the usability of a file iscompromised by an incomplete download.

1. A communications system comprising a network subsystem, wherein thecommunications system is configured to implement event based charging,and the communications system is to filter service flows between enduser equipments and application servers for charging purposes, whereinthe network subsystem is configured to: identify an instance of serviceflow between an end user equipment and a particular application server,send a first message containing information identifying a set of eventsto report, and receive a second message containing an event resultresponsive to occurrence of an event of the particular applicationserver that is one of the set of events and that is associated with theinstance of service flow, which event result is correlated with theinstance of service flow, the event result containing information aboutoccurrence of the event.
 2. A communications system according to claim 1wherein the network subsystem comprises at least a traffic planefunction (TPF) to perform the identifying, the sending, and thereceiving, and wherein the TPF is configured to correlate the eventresult with the instance of service flow.
 3. A communications systemaccording to claim 2, further comprising a billing system, wherein theTPF is configured to provide notification of the event result and theinstance of service flow to a billing system and the billing system isconfigured to implement at least one of debiting, crediting anddiscounting to the user of the end user equipment based on the eventresult.
 4. A communications system according to claim 1 wherein toidentify the instance of the service flow the network subsystem matchescharacteristics of the service flow to triggering criteria and appliesassociated triggering actions to the service flow.
 5. A communicationssystem according to claim 1 wherein to identify the instance of theservice flow the network subsystem is configured to matchcharacteristics of the service flow to triggering criteria and to applyassociated triggering actions to the service flow, including at leastone of the following: instructions on how to filter a service flowmatched to the triggering criteria; instructions on how to identify theinstance of service flow among those matched to the triggering criteria;instructions on how to dynamically filter the instance of service flow;identification of an event owner for the service flow that matched thetriggering criteria; indication of whether a time stamp should berecorded; identification of a set of events to be reported by the eventowner; maximum number of events to be reported for the instance ofservice flow; and maximum number of events allowed for the instance ofservice flow.
 6. A communications system according to claim 1 in whichthe network subsystem is configured to allocate a unique identifier tothe instance of service flow, and the communications system additionallyincludes a billing system configured to cooperate with the networksubsystem to implement at least one of pre-paid and post-paid billing inwhich the billing system correlates the event result with the instanceof service flow by using the unique identifier.
 7. A communicationssystem according to claim 1 additionally including a billing system,wherein the billing system, in response to the occurrence of the event,is configured to retrospectively amend charges incurred for the instanceof service flow before that event occurred.
 8. A communications systemaccording to claim 1 wherein the network subsystem is configured tocorrelate the event result with the instance of service flow by matchingthe event result to the instance of service flow and notifying a billingsystem of the match.
 9. A communications system according to claim 1wherein the event result is correlated with the instance of service flowby matching the event result to an event detected by the networksubsystem on the instance of service flow.
 10. A communications systemaccording to claim 1 wherein the occurred event is one of the following:a purchase of goods or services from the particular application server;a download of data from the particular application server; access to aspecific page on the particular application server; access to aparticular videoclip streaming service on the particular applicationserver; completion of a videoclip streaming from the particularapplication server; or a predetermined situation of usage of anapplication on the particular application server.
 11. The communicationssystem of claim 10, wherein the predetermined situation of usage of theapplication in the particular application server comprises an end userreaching a given score in a gaming application.
 12. A communicationssystem according to claim 1 wherein the network subsystem includes agateway GPRS support node (GGSN).
 13. The communications system of claim1, wherein the network subsystem is to further send a request to anetwork entity to request notification of information associated withthe instance of service flow, the information to enable billing for theinstance of service flow.
 14. A communications system according to claim13 wherein the network entity is a server operated by an operator of theapplication server.
 15. A communications system according to claim 13wherein the network subsystem is configured to allocate a uniqueidentifier to the instance of service flow and to include the uniqueidentifier in the request to the network entity.
 16. A communicationssystem according to claim 15 wherein the network entity includes theidentifier with the event result in the message received by the networksubsystem.
 17. A communications system according to claim 13 wherein thenetwork subsystem is configured to include at least one of the followingin the request to the network entity: a unique identifier allocated forthe instance of service flow; a set of flow characteristics for end userand session identification; a timestamp; a maximum number of events tobe reported; a maximum number of events allowed for the instance ofservice flow; and an address of a device to which event results are tobe sent.
 18. A communications system according to claim 13 additionallyincluding a billing system, wherein the network subsystem is configuredto allocate a unique identifier to the instance of service flow and tonotify the unique identifier to the network entity, wherein the uniqueidentifier is included by the network entity in the event result and thesecond message is sent to the billing system, and the network subsystemis configured to send results of filtering of the instance of serviceflow to the billing system identifying the instance of service flow bythe unique identifier, and wherein the billing system is configured tocorrelate the filtering results and the event result based on the uniqueidentifier.
 19. A network subsystem for implementing event basedcharging in a communications system by filtering service flows betweenend user equipments and application servers, the network subsystemhaving a computer-readable storage medium encoded with software thatwhen executed cause the network subsystem to: identify an instance ofservice flow between an end user equipment and a particular applicationserver; send a first message containing information identifying a set ofevents to report, and receive a second message responsive to occurrenceof an event that is one of the set of events at the particularapplication server for the instance of service flow, the second messagecontaining an event result that is correlated with the instance ofservice flow, and the event result containing information aboutoccurrence of the event.
 20. A network subsystem according to claim 19wherein the first message is to be sent to an event owner for theinstance of service flow and further requests information associatedwith the instance of service flow to enable billing for the instance ofservice flow.
 21. A network subsystem according to claim 20 whichincludes at least one of the following in the first message to the eventowner: a unique identifier allocated by the network subsystem for theinstance of service flow; a set of flow characteristics for end user andsession identification; a timestamp, as recorded by the networksubsystem; a maximum number of events to be reported; a maximum numberof events allowed for the instance of service flow; and an address of adevice to which the event owner should send event reports, if differentfrom the network subsystem.
 22. A network subsystem according to claim20 which is configured to allocate a unique identifier to the instanceof service flow and to include the identifier in the first message tothe event owner.
 23. A network subsystem according to claim 19 whereinto identify the instance of the service flow the network subsystem isconfigured to match characteristics of the service flow to triggeringcriteria and to apply associated triggering actions to the service flow.24. A network subsystem according to claim 19 wherein to identify theinstance of the service flow the network subsystem is configured tomatch characteristics of the service flow to triggering criteria and toapply associated triggering actions to the service flow, including atleast one of the following: instructions on how to filter the serviceflow matched to the triggering criteria; instructions on how to identifythe instance of service flow among those matched to the triggeringcriteria; instructions on how to dynamically filter the instance ofservice flow; identification of an event owner for the service flow thatmatched the triggering criteria; identification of a set of service flowcharacteristics to be sent to the event owner for end user and sessionidentification; indication of whether a time stamp should be recorded;identification of a set of events to be reported by the event owner;maximum number of events to be reported for the instance of serviceflow; and maximum number of events allowed for the instance of serviceflow.
 25. A network subsystem according to claim 19, wherein thesoftware when executed causes the network subsystem to correlate theevent result with the instance of service flow by matching the eventresult to the instance of service flow and notifying a billing system ofthe match.
 26. A network subsystem according to claim 19, wherein thesoftware when executed causes the network subsystem to correlate theevent result with the instance of service flow by matching the eventresult to an event detected by the network subsystem on the instance ofservice flow.
 27. A network subsystem according to claim 19 whichincludes a gateway GPRS support node.
 28. The network subsystem of claim19, wherein the network subsystem comprises at least one traffic planefunction.
 29. A computer server associated with an event owner of anapplication server for which event based charging is implemented forservice flows between end user equipments and the application server bya network subsystem filtering the service flows for charging purposes,wherein the computer server associated with the event owner isconfigured to: receive a first message from the network subsystemrequesting notification of a set of events associated with an instanceof service flow, and in response to occurrence of an event that is oneof the set of events at the application server, send a message to thenetwork subsystem containing an event result containing informationabout the occurrence of the event.
 30. A computer server associated withthe event owner according to claim 29 wherein the occurred event is oneof the following: a purchase of goods or services from the applicationserver; a download of data from the application server; access to aspecific page on the application server; access to a particularvideoclip streaming service on the application server; completion of avideoclip streaming from the application server; or a predeterminedsituation of usage of an application on the application server.
 31. Acomputer server associated with the event owner according to claim 29wherein the first message received from the network subsystem furthercontains at least one of the following: a unique identifier of theinstance of service flow allocated by the network subsystem; a set offlow characteristics for end user and session identification; atimestamp, as recorded by the network subsystem; a maximum number ofevents to be reported; a maximum number of events allowed for theinstance of service flow; and an address of the device to which theevent owner should send event results.
 32. A method of event basedcharging in a communications system wherein service flows between enduser equipments and application servers are filtered for chargingpurposes, the method comprising: a network subsystem identifying aninstance of service flow between an end user equipment and a particularapplication server; the network subsystem sending a first messagecontaining information identifying a set of events to report; thenetwork subsystem receiving a second message containing an event resultresponsive to occurrence of an event of the particular applicationserver that is one of the set of events and that is associated with theinstance of service flow, wherein the event result contains informationregarding occurrence of the event.
 33. A method according to claim 32wherein the network subsystem identifying the instance of the serviceflow includes the network subsystem matching characteristics of theservice flow to triggering criteria and applying associated triggeringactions to the service flow.
 34. A method according to claim 32 whereinthe network subsystem identifying the instance of service flow includesthe network subsystem matching characteristics of the service flow totriggering criteria and applying the associated triggering actions tothe service flow, including at least one of the following: instructionson how to filter the service flow matched to the triggering criteria;instructions on how to identify the instance of service flow among thosematched to the triggering criteria; instructions on how to dynamicallyfilter the instance of service flow.
 35. A method according to claim 32wherein an event owner performs generating the event result whichcontains information enabling an operator of the communications systemto confirm by filtering of the instance of service flow that the eventhas taken place.
 36. A method according to claim 32, further comprisingthe network subsystem correlating the event result with the instance ofservice flow by matching the event result to the instance of serviceflow and notifying a billing system of the match.
 37. A method accordingto claim 32, further comprising correlating the event result with theinstance of service flow by matching the event result to an eventdetected by the network subsystem on the instance of service flow.
 38. Amethod according to claim 32 wherein the occurred event is one of thefollowing: a purchase of goods or services from the particularapplication server; a download of data from the particular applicationserver; access to a specific page on the particular application server;access to a particular videoclip streaming service on the particularapplication server; completion of a videoclip streaming from theparticular application server; or a predetermined situation of usage ofan application on the particular application server.
 39. The method ofclaim 32, further comprising: the network subsystem sending a request toa network entity to request notification of information associated withthe instance of service flow.